Contact list aggregation and display

ABSTRACT

A technique for contact list aggregation across networks involves logging into low level networks through a high level network. A system constructed according to the technique may include a network interface coupled to the different low level networks. The system may further include a contact aggregation engine coupled to the network interface and a network contacts database. In operation the system logs into one or more of the low level networks (or facilitates login for a user). To the extent that the data in the network contacts database is not current, the contact aggregation engine updates the networks contacts database contact information, then provides an aggregated contact list including the contact information to a display device. A method according to the technique may include logging into a high level network and displaying contacts from the one or more low level networks in an aggregated contact list.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/706,652 filed Dec. 6, 2019, now U.S. Pat. No. 11,012,393, which is acontinuation of U.S. patent application Ser. No. 15/369,112 filed Dec.5, 2016, now U.S. Pat. No. 10,536,412, which is a continuation of U.S.patent application Ser. No. 13/941,354 filed Jul. 12, 2013, now U.S.Pat. No. 9,584,453, which is continuation of U.S. patent applicationSer. No. 12/774,700 filed May 5, 2010, now U.S. Pat. No. 8,510,395,which is a continuation of U.S. patent application Ser. No. 11/637,316filed Dec. 11, 2006, which claims priority to U.S. Provisional PatentApplication No. 60/748,988 filed Dec. 9, 2005, all of which areincorporated herein by reference.

BACKGROUND

Instant messaging requires the use of a client program that hooks up aninstant messaging service and differs from e-mail in that conversationsare then able to happen in real time. Most services offer a presenceinformation feature, indicating whether people on one's list of contactsare currently online and available to chat. This may be called a contactlist. In early instant messaging programs, each letter appeared as itwas typed, and when letters were deleted to correct typos this was alsoseen in real time. This made it more like a telephone conversation thanexchanging letters. In modern instant messaging programs, the otherparty in the conversation generally only sees each line of text rightafter a new line is started. Most instant messaging applications alsoinclude the ability to set a status message, roughly analogous to themessage on a telephone answering machine.

Popular instant messaging services on the public Internet include .NETMessenger Service, AOL Instant Messenger, Excite/Pal, Gadu-Gadu, GoogleTalk, iChat, ICQ, Jabber, Qnext, QQ, Meetro, Skype, Trillian and Yahoo!Messenger. These services owe many ideas to an older (and still popular)online chat medium known as Internet Relay Chat (IRC).

The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will become apparent to those of skill inthe art upon a reading of the specification and a study of the drawings.

SUMMARY

The following embodiments and aspects thereof are described andillustrated in conjunction with systems, tools, and methods that aremeant to be exemplary and illustrative, not limiting in scope. Invarious embodiments, one or more of the above-described problems havebeen reduced or eliminated, while other embodiments are directed toother improvements.

A technique for contact list aggregation across a plurality of differentnetworks involves logging into low level networks through a high levelnetwork. A system constructed according to the technique may include anetwork interface coupled to the different low level networks. Thesystem may further include a contact aggregation engine coupled to thenetwork interface and a network contacts database. In operation thesystem logs into one or more of the low level networks (or facilitateslogin for a user). The network contacts database may include someinformation about contacts associated with the networks from, by way ofexample but not limitation, previous logins or data explicitly enteredby a user. To the extent that the data in the network contacts databaseis not current, the contact aggregation engine updates the networkscontacts database contact information, then provides an aggregatedcontact list including the contact information to a display device.

A method according to the technique may include logging into a highlevel network and displaying contacts from the one or more low levelnetworks in an aggregated contact list. The method may further includelogging into the one or more low level networks.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the inventions are illustrated in the figures. However,the embodiments and figures are illustrative rather than limiting; theyprovide examples of the invention.

FIG. 1 depicts an example of a system for providing instant messages toclients via a web interface.

FIG. 2 depicts an example of a system for displaying content from an IMclient at an alternative IM client.

FIG. 3 depicts an example of a system capable of contact aggregation anddisplay.

FIGS. 4A-4B depict examples of screenshots that depicts a multi-networkIM display.

FIG. 5 depicts a flowchart of an example of a method for contact listaggregation and display.

FIG. 6 depicts a flowchart of an example of a method for aggregatedcontact list display.

FIG. 7 depicts a computer system suitable for implementation of thetechniques described with reference to FIGS. 1-6.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding of embodiments of the invention. Oneskilled in the relevant art will recognize, however, that the inventioncan be practiced without one or more of the specific details, or incombination with other components, etc. In other instances, well-knownimplementations or operations are not shown or described in detail toavoid obscuring aspects of various embodiments, of the invention.

FIG. 1 depicts an example of a system 100 for providing instant messagesto clients via a web interface. In the example of FIG. 1, the system 100includes a network 102, a server 104, and an Instant Messenger (IM)server 106, and an IM network 108. The server 104 is coupled to thenetwork at least by way of port 80. The two way communication via port80 is represented in the example of FIG. 1 as an arrow 110. The server104 is coupled to the IM server 106 via one or more other ports. The twoway communication via the other ports is represented in the example ofFIG. 1 as an arrow 112. The IM server 106 is coupled to the IM network108 via any known or convenient mechanism. Indeed, the IM server 106 maybe thought of as part of the IM network 108. The network 102 couples aplurality of clients 114-1 to 114-N (referred to collectively as clients114) to the server 104. In the example of FIG. 1, the server 104includes an event queue 116.

The network 102 may include by way of example but not limitation LAN,WAN, VLAN, WLAN, Internet, cellular network, phone network, radionetwork, or some other known or convenient network. The term “Internet”as used herein refers to a network of networks that uses certainprotocols, such as TCP/IP, and possibly other protocols such as thehypertext transfer protocol (HTTP) for hypertext markup language (HTML)documents that make up the World Wide Web (the web). The physicalconnections of the Internet and the protocols and communicationprocedures are well known, but any convenient physical connections orprotocols could be used.

The server 104 may include a multiple servers. Indeed, it may bedesirable, depending upon details of a particular implementation, toinstall several servers to cope with the number of simultaneous usersthe system 100 supports. It may further be desirable, depending upondetails of a particular implementation, for the server 104 to have ahigh CPU throughput, together with large amounts of RAM, to handle alarge number of users. It may further be desirable, depending upondetails of a particular implementation, to accomplish resource sharingvia thread handling where a pool of threads is shared and used by one ormore of the clients 114 for client-server communication and between theserver 104 and the IM server 106.

The server 104 may include one or more of an application server,database server, web server, banners server, and content server, or anycombination thereof. To make the most of the techniques describedherein, the server 104 should, though is not required to, include atleast one application server. The other servers can have supportingroles in, by way of example but not limitation, serving static contentor advertising (e.g., banners), storing usage data, or fulfilling someother known or convenient function.

The server 104 may act as a proxy server between the clients 114 and theIM server 106. The server 104 receives communications from the clients114 on http port 80, and responds to the clients 114 on http port 80.Communications from the clients 114 that are bound for the IM network108, however, must also come through http port 80 to the server 104, andare then forwarded to the IM server 106. In this way, the server 104acts as a carrier of the data from users to the IM network 108 using amechanism that controls and manages the data (e.g., text messages,display images, emoticons, audio/video streams, etc.) sent between oneof the clients 114 and the server 104, and vice versa.

The IM server 106 may be any known or convenient IM server that iscompatible with IM. Events, messages, or other appropriate data from theIM server 106 are collected in the event queue 116 of the server 104.The events may be collected in association with a variety of protocolsincluding by way of example but not limitation port 1863, port 5050,port 5222, port 5190, etc.

The IM network 108 may include one or a combination of networks selectedfrom MSN Messenger, Yahoo! Messenger, AIM AOL, ICQ, QQ, Jabber, GoogleTalk, IRC, or some other known or convenient IM network.

The clients 114 may include any known or convenient device, including byway of example but not limitation, a Web browser, mobile client, PDA,game console, TV box, native application, etc. The clients poll theserver 104 for events. The events can be removed from the event queue116 and translated into text, JavaScript, XML, or some other known orconvenient format that one or more of the clients 114 need or expect inorder to process data associated with the event.

To interact with the IM network 108, the clients 114 send data to theserver 104. The data, which may include commands, is processed andtranslated into corresponding data that will be sent to the appropriateIM network. In an embodiment, the appropriate IM network may bedeterminable based upon the protocol encoded in a message.

Messages or actions from the clients 114 are collected over networkprotocols such as, by way of example but not limitation, HTTP or plainsocket connections. The messages or actions are transformed to anappropriate protocol format to be sent over a compliant port from theclients 114 to the server 104, with the IM protocol on the applicationside. In a non-limiting embodiment, the compliant port is http port 80.However, any port having similar characteristics to those of a typicalport 80 could be used.

The latest available browsers, as of December 2005, enable the use of atechnique called AJAX (Asynchronous JavaScript And XML). With AJAX,appropriately configured clients 114 can execute actions and poll formessages or events using only JavaScript. The method is based on usingan XMLHttpRequest object to make HTTP requests to the server 104. Theserver 104 may reply with messages taken from the queue of thecorresponding session in XML (or another) format that are parsed anddisplayed according to the message content.

For clients 114 that include a browser, when accessing the server 104the browser typically uses hidden HTML frames to update information onvisible frames. The visible frames display appropriate information whilethe hidden frames are reloaded in short periods of time. In each refreshthat hits the server 104, the browser identifies the current messagingsession and checks if new events or messages associated with the sessionare in the event queue 116. When new information arrives and needs to bedisplayed in some form, the browser makes use of, for example,JavaScript code to update the visible frames and windows with newmessages or events keeping the information up to date in the screen. Inthis way, automatic refreshing can take place in a hidden frame.

In another embodiment, certain of the clients 114 with browsers may notmake use of refreshes. For example, a form of updating the screenwithout using a refresh technique is to keep one single HTTP socketrequest alive for the whole period of a messaging session withoutactually closing the socket connection. In this example, information isinitially loaded and displayed in one single visible frame. While eventsand messages are being received by the server 104, JavaScript code canbe injected into the HTML document through the same HTTP socket keptalive and managed by the server 104. For each event or message, thebrowser can interpret the JavaScript code injected and the correspondingparts of the HTML document and windows will be updated.

In another embodiment, certain of the clients 114 with browsers may makeuse of manual refreshes. Some relatively unsophisticated browsers, suchas WAP and xHTML browsers often available on mobile phones, do notsupport hidden frames and/or JavaScript (and others may be configuredsuch that they do not support hidden frames and/or JavaScript). In suchcases, the information displayed has to be updated manually by the user.Manual updating enables any mobile phone, PDA, TV Set or any device witha browser to connect to the server 104 and use the messaging platformsmade available by the server 104 assuring the communication between theclients 114 and the IM server 106.

Message history can be stored by most IM clients on a local computer.For alternative web and mobile-based clients local storage may not bepossible. In a non-limiting embodiment, the server 104, may have thecapability to store message history from IM conversations done via oneor more of the clients 114. The message history can be accessed andsearched at any time via the server 104 by one or more of the clients114

FIG. 2 depicts an example of a system 200 for displaying content from anIM client at an alternative IM client. In the example of FIG. 2, thesystem 200 includes a client 202, an IM network 204, a server 206, an IMnetwork 208, a client 210, other IM networks 212-1 to 212-N (referred tocollectively as other IM networks 212), and other clients 214-1 to 214-N(referred to collectively as other clients 214).

For illustrative purposes, it is assumed that the client 202 has contentthat is compatible with the IM network 204. However, the client 210 iscapable of reading content formatted to be compatible with the IMnetwork 208. Thus, in operation, the server 206 collects content fromthe client 202 (either through the IM network 204, as shown in FIG. 2,or directly from the client 202, such as is shown by way of example inFIG. 1). The server 206 then formats the content as appropriate for useon the IM network 208. Once the content is properly formatted, it can bemade available to the client 210 (either through the IM network 208, asshown in FIG. 2, or directly to the client 210, such as is shown by wayof example in FIG. 1). Depending upon the embodiment and/orimplementation, the content may also be formatted as appropriate for oneor more of the other IM networks 212, to be made available for one ormore of the other clients 214.

In an embodiment, the server 206 can save the content in one or manyformats. In this way, the client 202 could make content available in afirst IM format, the server 206 could convert the content into a secondIM format, and the server 206 can save the content in at least thesecond IM format. Thus, the client 210 could receive the data in thesecond IM format. The server 206 could easily store the content in thefirst IM format, as well, and make the content available to otherclients coupled to the IM network 204. In addition, the server 206 couldconvert the content to other IM formats, such as those formats that areassociated with the other IM networks 212, and save the other IMformats. In this way, the other clients 214 may have access to thecontent.

In a non-limiting embodiment, the client 202 may be able to view theclient 210 and the clients 214 simultaneously. This is advantageousbecause IM clients typically cannot view IM clients from other IMnetworks. Advantageously, since the server 206 is used, the client 202could even include, for example, a mobile device without a client. (Ofcourse, this could be interpreted to mean that the client 202 is not anIM client at all, though the term client is still used for illustrativepurposes because the client 202 is served by the server 206 in aclient-server-like fashion.) In a non-limiting embodiment, if the client202 does not or cannot install client software, the client 202 can use abrowser for web-based messaging and display.

FIG. 3 depicts an example of a system 300 capable of contact aggregationand display. The system 300 includes low level networks 302-1 to 302-N(collectively referred to as the low level networks 302), a computer304, and a display 306. The low level networks 302 may include, by wayof example but not limitation, various IM networks. It may be noted thatthe computer 304 and the display 306 may be referred to, in certainimplementations, as comprising a computer system.

The computer 304 includes a network interface 308, network login engines310-1 to 310-N (collectively referred to as network login engines 310),network contacts databases 312-1 to 312-N (collectively referred to asthe network contacts database 312), a high level contacts database 314,a user profile database 316, and a contact aggregation engine 318.

The network interface 308 is coupled to the low level networks 302. In atypical implementation, the network interface 308 also couples thecomputer 304 to a network such as the Internet and/or a high levelnetwork (not shown).

The network login engines 310 may include logic and storage thatfacilitates login to the various low level networks 302. For example,the network login engine 310-1 may include a user name (and perhaps apassword, if the password is not requested from the user at each login)associated with the low level network 302-1. Conceptually, each of thenetwork login engines 310 is intended to represent the capability oflogin to the low level networks 302 in a general sense (i.e., the dataand logic required for any device to connect to the low level networks302) and a user-specific sense (e.g., the data provided from a user thatenables login to accounts associated with the user).

The network contacts database 312, which is embodied in acomputer-readable medium, includes contacts data associated with any ofthe networks into which a user has logged. When a user logs out, thedata may or may not be cached (or stored in nonvolatile memory) forfuture reference, depending upon the implementation and/or userconfiguration.

The high level contacts database 314, which is embodied in acomputer-readable medium, is an optional database that includes contactsassociated with a high level network. The high level contacts databaseis optional for at least two reasons. The first reason is that a systemneed not provide the ability to maintain high level contacts, requiringthat a user maintain only low level contacts. The second reason is thateven if the system provides the ability to maintain high level contacts,a user may opt not to maintain any high level contacts, opting insteadfor low level contacts.

The user profile database 316, which is embodied in a computer-readablemedium, is intended to represent data associated with a user. The amountof data maintained is implementation-specific.

The contact aggregation engine 318 is coupled to the databases 312, 314,316, the network login engines 310, and the display 306. In operation,the contact aggregation engine 318 controls the network login engines310 to login to or facilitate login by a user to the various low levelnetworks 302. The databases 312, 314, 316 are accessed in such a waythat a list of contacts stored in the network contacts database 312 isaggregated and displayed on the display 306, as illustrated by thescreenshots of FIGS. 4A-4B, and the flowcharts of FIGS. 5-6.

FIGS. 4A-4B depict examples of screenshots that depicts a multi-networkIM display. In many cases, a user will login to a high level account andadjust user configurations such that the system will automatically loginthe user to various low level accounts. This may require storing logincredentials so that the system can automatically login the user to eachselected interface. FIG. 4A depicts an example of a screenshot 400A fora full screen display. In the example of FIG. 4A, the screenshot 400Aincludes a contacts list tab 402, an “add a network” hyperlink 404, aplurality of MSN icons 406, a plurality of Yahoo! icons 408, and aplurality of AIM icons 410.

As the name implies, the contacts list tab 402 includes a listing ofdesignated IM client contacts. For an IM client to be included in thelisting, a user associated with the contact list typically mustexplicitly enter a client into the list. This may be accomplished with asingle click. For example, when a new IM client contacts the user, theuser may be prompted to allow the IM client to be entered into theuser's contacts list.

As is suggested by the folders depicted in the contacts list tab 402, auser may organize contacts in various folders. A single contact may belisted in no folders, one folder, or multiple folders, depending uponimplementation and user configurations. Depending upon theimplementation details, all contacts who are not currently online arelisted in the “Offline” folder.

The “add a network” hyperlink 404 can be followed to add networks fordisplay. In a non-limiting embodiment, when a network is added, contactsof the user in the added network are added to the contacts list tab 402.The added contacts are distinguishable by network using, for example,the icons 406, 408, 410.

In an alternative embodiment, the contact list could be maintained in ahigh level network (i.e., all contacts are listed in the contact list,even if the contacts are from a network that has not been added). If acontact is a member of a network that is not added, the contact wouldpresumably be listed in the “Offline” folder because the contact is notknown to the user to be online. However, depending upon theimplementation, the “Offline” folder could be effectively split into twofolders, if desired, one which indicates a contact is offline, and onethat indicates a contact is a member of a network that has not beenadded. In the example of FIG. 4A, this is implicit because the addednetworks have icon 406, 408, 410 associated with them, and each of thecontacts have icons 406, 408, 410 associated with them. So, it isapparent from viewing the display whether a contact is or is not amember of a network that is currently added.

In a non-limiting embodiment, adding a network requires that the user bea member of the added network. For example, if the user wishes to addthe MSN IM network, the user must have an IM account with MSN. However,in an alternative embodiment, a system could set up a dummy account fora user who wishes to add an account for a network with which the user isnot a member. The dummy account will be associated with the user, butthe user might feel more comfortable with not ever logging in,remembering a password, etc. The system could handle all of thesedetails for the user without the user's knowledge, and without exposingthe user to security risks such as compromised passwords (since someusers use the same password for multiple accounts, but in this case thesystem would generate a random, and presumably strong, password for usewith the account).

FIG. 4B depicts an example of a screenshot 400B for a mobile phonedisplay. In the example of FIG. 4B, the contact list includes a seriesof contacts and their associated network-identifying icons 406, 408,410. The information available on a mobile phone display is less thanthat of a full screen display, such as is available on, for example, alaptop display.

In the example of FIG. 4B, a user can add accounts by clicking on an“add account” hyperlink 412. Depending upon the implementation, clickingon the “add account” hyperlink 412 could prompt the user to select anaccount from a list of accounts the user has already designated in acontacts list (or add a new account), to select a list of accountsassociated with a particular subset (see, e.g., the folders of FIG. 4A),to select a particular network (which may include logging the user in tothe network or prompting the user to do so), storing login credentialsand, when logging in, the system can automatically login the user toeach selected interface, or to select accounts in some other manner.Presumably, if an account is selected for a contact that is a member ofa network in which the user has not logged in, in a non-limitingembodiment, either the user or the system will have to login to thenetwork.

In the example of FIG. 4B, the user can remove accounts from the onlinelist by clicking on a “signout” hyperlink 414 next to the accounts.Depending on the implementation, clicking on the “signout” hyperlink 414may cause the user to go offline with respect to the account associatedwith the particular “signout” hyperlink, or with all accounts on thesame network as the account associated with the particular “signout”hyperlink. A “signout” hyperlink 416 may be used to sign out of allnetworks at once or, in a different implementation, cause the user to beprompted regarding the networks from which to sign out.

In the example of FIG. 4B, the screenshot 400B includes a “reload”hyperlink 418. It may be desirable to occasionally refresh the screen.Some mobile devices may even be incapable of refreshing without anexplicit reload.

FIG. 5 depicts a flowchart 500 of an example of a method for contactlist aggregation and display. This method and other methods are depictedas serially arranged modules. However, modules of the methods may bereordered, or arranged for parallel execution as appropriate. In theexample of FIG. 5, the flowchart 500 begins at module 502 where a highlevel network is joined. A high level network may include, by way ofexample but not limitation, eBuddy.

In the example of FIG. 5, the flowchart 500 continues to module 504where a low level network is joined. Low level networks may include IMnetworks, such as MSN Messenger, Yahoo! Instant Messenger, AIM, or anyother known or convenient network. It should also work properly if highlevel networks were joined as if the high level networks were low level.For example, a member of a first high level network could join a secondhigh level network, which in turn is associated with first and secondlow level networks. The second high level network would function ratherlike a node in a tree, where the first high level network is the root,and the leaves of the node are the first and second low level networks.Thus, the second high level network could be thought of as a mid-levelnetwork. Unless a distinction is needed, mid-level networks are treatedas low level networks herein.

In the example of FIG. 5, the flowchart 500 continues to decision point506 where it is determined whether to join more low level networks. Ifit is determined that more low level networks are to be joined (506-Y),then the flowchart 500 loops back to module 504, as describedpreviously. If, on the other hand, it is determined that no more lowlevel networks are to be joined (506-N), then the flowchart 500continues to module 508 where a contact list associated with one or moreof the low level networks is maintained.

While contact lists are not particularly important in email environments(because you can write an email to anyone whose email address you know),in IM environments, contact lists are more desirable because users wantto see who is online before sending an IM. If a contact is not online,IM is not allowed in many implementations (and in an implementation that“allows” IM with an offline contact, the communication is arguably notan instant message). Accordingly, at least in an IM environment, mostusers will maintain a contact list (508).

In the example of FIG. 5, the flowchart 500 continues to module 510where the high level networks is logged into. When a user logs into ahigh level network, the user will typically have a number of options,including requesting that a list of contacts be displayed. The list ofcontacts could also be displayed automatically upon login, dependingupon the implementation and user configurations.

In the example of FIG. 5, the flowchart 500 continues to module 512where contacts from each of the low level networks are displayed in anaggregated contact list. Depending upon the implementation or userconfiguration, the contact list could include high level contacts, too.Also depending upon the implementation and/or user configuration, theuser may or may not be required to login to each of the low levelnetworks for which contacts are to be displayed in the aggregatedcontact list.

In the example of FIG. 5, the flowchart 500 continues to decision point514 where it is determined whether to quit the high level network. Ifthe user does not quit the high level network (514-N), then theflowchart 500 continues to decision point 516 where it is determinedwhether the user logs out of the high level network. If it is determinedthat the user is to logout of the high level network (516-Y), then theflowchart 500 continues to module 518 where the user logs out. Whetherthe user logs out (516-Y, 518), or not (516-N), the flowchart 500 loopsback to decision point 506, as described previously.

In many cases, a user may never quit the high level network, however itis theoretically possible that a user would quit (or a user would bebanned). If the user quits or is banned from the high level network(514-Y), then the flowchart 500 ends.

FIG. 6 depicts a flowchart 600 of an example of a method for aggregatedcontact list display. In the example of FIG. 6, the flowchart 600 startsat module 602 where a member logs into a high level network.

In the example of FIG. 6, the flowchart 600 continues to module 604where a user logs into a low level network through the high levelnetwork. Depending upon the implementation and/or user configurations,the user may be logged into the low level network automatically whenlogging into the high level network, explicitly by the user, or the usermay be logged into the low level network when the user selects a contactthat is associated with the low level network.

In the example of FIG. 6, the flowchart 600 continues to module 606where high level and low level contacts are displayed in an aggregatedcontact list. It may be noted that a user may not have a high levelcontact list, either because a high level system does not allow forcontact lists, or because the user does not opt to maintain any contactlists at the high level.

In the example of FIG. 6, the flowchart 600 continues to decision point608 where it is determined whether to logout of the low level network.If it is determined to logout of the low level network (608-Y), then theflowchart 600 continues to module 610 where the relevant low levelcontacts are removed from the aggregated display, and the flowchart 600loops back to module 606, as described previously. The relevant lowlevel contacts are those contacts that are in the contact listassociated with the low level network from which logout was elected. If,on the other hand, it is determined not to logout of the low levelnetwork (608-N), then the flowchart 600 continues to decision point 612.

In the example of FIG. 6, the flowchart 600 continues to decision point612 where it is determined whether to login to a low level network. Itis possible to login to an implementation-specific number of low levelnetworks (or, in the alternative, practically any number of low levelnetworks). If it is determined to login to a low level network (612-Y),then the flowchart 600 loops back to module 604, as describedpreviously. If, on the other hand, it is determined not to login to alow level network (612-N), then the flowchart 600 continues to decisionpoint 614, where it is determined whether to logout of the high levelnetwork. If not (614-N), the flowchart 600 loops back to module 606, asdescribed previously. If so (614-Y), then the flowchart 600 ends.

FIG. 7 depicts a computer system 700 suitable for implementation of thetechniques described above with reference to FIGS. 1-6. The computersystem 700 includes a computer 702, I/O devices 704, and a displaydevice 706. The computer 702 includes a processor 708, a communicationsinterface 710, memory 712, display controller 714, nonvolatile storage716, and I/O controller 718. The computer 702 may be coupled to orinclude the I/O devices 704 and display device 706.

The computer 702 interfaces to external systems through thecommunications interface 710, which may include a modem or networkinterface. The communications interface 710 can be considered to be partof the computer system 700 or a part of the computer 702. Thecommunications interface 710 can be an analog modem, ISDN modem, cablemodem, token ring interface, satellite transmission interface (e.g.“direct PC”), or other interfaces for coupling a computer system toother computer systems. Although conventional computers typicallyinclude a communications interface of some type, it is possible tocreate a computer that does not include one, thereby making thecommunications interface 710 optional in the strictest sense of theword.

The processor 708 may include, by way of example but not limitation, aconventional microprocessor such as an Intel Pentium microprocessor orMotorola power PC microprocessor. While the processor 708 is a criticalcomponent of all conventional computers, any applicable known orconvenient processor could be used for the purposes of implementing thetechniques described herein. The memory 712 is coupled to the processor708 by a bus 720. The memory 712, which may be referred to as “primarymemory,” can include Dynamic Random Access Memory (DRAM) and can alsoinclude Static RAM (SRAM). The bus 720 couples the processor 708 to thememory 712, and also to the non-volatile storage 716, to the displaycontroller 714, and to the I/O controller 718.

The I/O devices 704 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. For illustrative purposes, at least one of the I/Odevices is assumed to be a block-based media device, such as a DVDplayer. The display controller 714 may control, in a known or convenientmanner, a display on the display device 706, which can be, for example,a cathode ray tube (CRT) or liquid crystal display (LCD).

The display controller 714 and I/O controller 718 may include devicedrivers. A device driver is a specific type of computer softwaredeveloped to allow interaction with hardware devices. Typically thisconstitutes an interface for communicating with the device, through abus or communications subsystem that the hardware is connected to,providing commands to and/or receiving data from the device, and on theother end, the requisite interfaces to the OS and software applications.

The device driver may include a hardware-dependent computer program thatis also OS-specific. The computer program enables another program,typically an OS or applications software package or computer programrunning under the OS kernel, to interact transparently with a hardwaredevice, and usually provides the requisite interrupt handling necessaryfor any necessary asynchronous time-dependent hardware interfacingneeds.

The non-volatile storage 716, which may be referred to as “secondarymemory,” is often a magnetic hard disk, an optical disk, or another formof storage for large amounts of data. Some of this data is oftenwritten, by a direct memory access process, into memory 712 duringexecution of software in the computer 702. The non-volatile storage 716may include a block-based media device. The terms “machine-readablemedium” or “computer-readable medium” include any known or convenientstorage device that is accessible by the processor 608 and alsoencompasses a carrier wave that encodes a data signal.

The computer system 700 is one example of many possible computer systemswhich have different architectures. For example, personal computersbased on an Intel microprocessor often have multiple buses, one of whichcan be an I/O bus for the peripherals and one that directly connects theprocessor 708 and the memory 712 (often referred to as a memory bus).The buses are connected together through bridge components that performany necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedin conjunction with the teachings provided herein. Network computers donot usually include a hard disk or other mass storage, and theexecutable programs are loaded from a network connection into the memory712 for execution by the processor 708. A Web TV system, which is knownin the art, is also considered to be a computer system, but it may lacksome of the features shown in FIG. 6, such as certain input or outputdevices. A typical computer system will usually include at least aprocessor, memory, and a bus coupling the memory to the processor.

The computer system 700 may be controlled by an operating system (OS).An OS is a software program—used on most, but not all, computersystems—that manages the hardware and software resources of a computer.Typically, the OS performs basic tasks such as controlling andallocating memory, prioritizing system requests, controlling input andoutput devices, facilitating networking, and managing files. Examples ofoperating systems for personal computers include Microsoft Windows®,Linux, and Mac OS®. Delineating between the OS and application softwareis sometimes rather difficult. Fortunately, delineation is not necessaryto understand the techniques described herein, since any reasonabledelineation should suffice.

The lowest level of an OS may be its kernel. The kernel is typically thefirst layer of software loaded into memory when a system boots or startsup. The kernel provides access to various common core services to othersystem and application programs.

As used herein, algorithmic descriptions and symbolic representations ofoperations on data bits within a computer memory are believed to mosteffectively convey the techniques to others skilled in the art. Analgorithm is here, and generally, conceived to be a self-consistentsequence of operations leading to a desired result. The operations arethose requiring physical manipulations of physical quantities. Usually,though not necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It has proven convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer that manipulates and transforms data representedas physical (electronic) quantities within the computer system'sregisters and memories into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

An apparatus for performing techniques described herein may be speciallyconstructed for the required purposes, or it may comprise a generalpurpose computer selectively activated or reconfigured by a computerprogram stored in the computer. Such a computer program may be stored ina computer readable storage medium, such as, by way of example but notlimitation, read-only memories (ROMs), RAMs, EPROMs, EEPROMs, magneticor optical cards, any type of disk including floppy disks, opticaldisks, CD-ROMs, DVDs, and magnetic-optical disks, or any known orconvenient type of media suitable for storing electronic instructions.

The algorithms and displays presented herein are not inherently relatedto any particular computer architecture. The techniques may beimplemented using any known or convenient programming language, whetherhigh level (e.g., C/C++) or low level (e.g., assembly language), andwhether interpreted (e.g., Perl), compiled (e.g., C/C++), orJust-In-Time (JIT) compiled from bytecode (e.g., Java). Any known orconvenient computer, regardless of architecture, should be capable ofexecuting machine code compiled or otherwise assembled from any languageinto machine code that is compatible with the computer's architecture.

As used herein, the term “embodiment” means an embodiment that serves toillustrate by way of example but not limitation.

It will be appreciated to those skilled in the art that the precedingexamples and embodiments are exemplary and not limiting to the scope ofthe present invention. It is intended that all permutations,enhancements, equivalents, and improvements thereto that are apparent tothose skilled in the art upon a reading of the specification and a studyof the drawings are included within the true spirit and scope of thepresent invention. It is therefore intended that the following appendedclaims include all such modifications, permutations and equivalents asfall within the true spirit and scope of the present invention.

1. A system comprising: a network login engine; a contact aggregationengine coupled to the network login engine; wherein, in operation, thecontact aggregation engine is configured to: control the network loginengine to login or facilitate login to a plurality of networks includinga first network and a second network, aggregate a first contact listincluding contact information associated with the first network and asecond contact list including contact information associated with thesecond network to obtain an aggregated contact list, provide theobtained aggregated contact list to a display device.